This crate is very conservative about breaking changes. More than 17000 downstream crates depend on unicode-bidi, so even very rare situations can come up frequently among our users. We try not to make changes like this unless there is some important benefit that outweighs the risk of downstream breakage.

For whatever it's worth unicode-bidi only has 15 public dependents listed on crates.io and none of them directly depend on serde 0.8 or 0.9. The vast majority of downloads come from only 2 crates: idna and stringprep.

That figure was including transitive dependencies, mostly via the url crate which depends on idna. It's true that idna does not use the serde feature of this crate, which does limit the possible impact.

However, it does mean that bumping the major version of this crate is highly disruptive, and that would be technically required for a breaking change like this...

Maybe I'm just confused here but why would this be a breaking change? The crate can already use serde 1.0, this would just ensure that.

Most Rust crates do not consider bumps to their dependencies to affect semver, but the closer you are to the bottom of the dep graph, the more you have to care about this stuff because it is possible to break builds by forcing there to be multiple incompatible versions of a crate (which sometimes works and sometimes fails builds).

Concretely, this would break a crate that depends on unicode-bidi with the serde feature enabled, and also depends directly on serde version 0.8.x, and passes (for example) a unicode_bidi::Level to the serde::Serialize::serialize function.

In the language of RFC 1977, serde is a “public dependency” of unicode-bidi. As discussed in that RFC, “if you bump a public dependency's version, it's a breaking change of your own crate.”

(And I'll caveat this by mentioning that a large subset of the community does ignore the de jure concept of public-dependency semver breakages, following a de facto definition that doesn't incorporate dependency changes, however as a heavily used dependency we are more beholden to the stricter de jure definition as compared to the de facto definition)

☔ The latest upstream changes (presumably #127) made this pull request unmergeable. Please resolve the merge conflicts.